The present invention relates to database systems.
In conventional relational databases, all data are stored in named tables. The tables are described by their features. In other words, the rows of each table contain items of identical type, and the definitions of the columns of the table (i.e., the column names and the data types stored in the column) describe the attributes of each of the instances of the object. By identifying its name, its column names and the data types of the column contents, a table is completely described. Queries to a relational data base are formulated in a query language. One such language is SQL (Structure Query Language) which is widely used in commercial relational data base systems. The data types offered by SQL can be classified as character arrays (names), numbers, and data types related to date and time. Tables can be modified or combined by several operations of relational algebra such as the application of Boolean operators, projection (i.e. selection of columns) or the Cartesian product.
Relational databases offer several advantages. Data base queries are based on a comparison of the table contents. Thus, no pointers are required in relational databases, and all relations are treated uniformly. Further, the tables are independent (they are not related by pointers), so it is easier to maintain dynamic data sets. The tables are easily expandable by simply adding new columns. Also, it is relatively easy to create user-specific views from relational databases.
There are, however, a number of disadvantages associated with relational databases as well. For example, access to data by reference to properties is not optimal in the classical relational data model. This can make such databases cumbersome in many applications.
Another recent technology for database systems is referred to as object oriented data base systems. These systems offer more complex data types in order to overcome the restrictions of conventional relational databases. In the context of object oriented data base models, an “object” includes both data and the functions (or methods) which can be applied to the object. Each object is a concrete instance of an object class defining the attributes and methods of all its instances. Each instance has its unique identifier by which it can be referred to in the database.
Object oriented databases operate under a number of principles. One such principle is referred to as inheritance. Inheritance means that new object classes can be derived from another class. The new classes inherit the attributes and methods of the other class (the super-class) and offer additional attributes and operations. An instance of the derived class is also an instance of the super-class. Therefore, the relation between a derived class and its super-class is referred to as the “isA” relation.
A second principle related to object oriented databases is referred to as “aggregation.” Aggregation means that composite objects may be constructed as consisting of a set of elementary objects. A “container object” can communicate with the objects contained therein by their methods of the contained objects. The relation between the container object and its components is called a “partOf” relation because a component is a part of the container object.
Yet another principle related to object oriented databases is referred to as encapsulation. According to encapsulation, an application can only communicate with an object through messages. The operations provided by an object define the set of messages which can be understood by the object. No other operations can be applied to the object.
Another principle related to object oriented databases is referred to as polymorphism. Polymorphism means that derived classes may re-define methods of their super-classes.
Objects present a variety of advantages. For example, operations are an important part of objects. Because the implementations of the operations are hidden to an application, objects can be more easily used by application programs. Further, an object class can be provided as an abstract description for a wide variety of actual objects, and new classes can be derived from the base class. Thus, if an application knows the abstract description and using only the methods provided by, the application can still accommodate objects of the derived classes, because the objects in the derived classes inherit these methods. However, object oriented databases are not yet as widely used in commercial products as relational databases.
Yet another database technology attempts to combine the advantages of the wide acceptance of relational data bases and the benefits of the object oriented paradigm. This technology is referred to as object-relational database systems. These databases employ a data model that attempts to add object oriented characteristics to tables. All persistent (database) information is still in tables, but some of the tabular entries can have richer data structure. These data structures are referred to as abstract data types (ADTs). An ADT is a data type that is constructed by combining basic alphanumeric data types. The support for abstract data types presents certain advantages. For example, the methods associated with the new data type can be used to index, store, and retrieve records based on the content of the new data type.
Some conventional object-relational databases support an extended form of SQL, sometimes referred to as ObjectSQL. The extensions are provided to support the object model (e.g., queries involving object attributes). However, these object-relational databases are still relational because the data is stored in tables of rows and columns, and SQL, with some extensions, is the language for data definition, manipulation, and query. Both the target of a query and the result of a query are still tables. The extended SQL language is often still the primary interface to the database. Therefore, there is no direct support of host object languages and their objects. This forces programmers to continue to translate between objects and tables.
The aforementioned database systems provide means for storing complex information in financial and business applications to name a few. By way of example, a business application may include objects that relate to customers, which in turn are related to various locations that they may have operating plants, types of products that each of these plants may order, the cost of such products, shipping dates, etc. The data for such information can be stored as properties of objects. However, some or all of the values that can be entered in the properties must be within acceptable ranges to avoid run-time errors, or worse, errors that do not necessarily cause a runtime error, but would corrupt the reliability of the application to maintain such data. For instance, many business objects are complex and part of that complexity is related to property dependency. For example, for a line item on a sales order object, the line items inventory identifier property may need to be set before the line items unit price property. If a consumer or user of the application is allowed to set the unit price property before the inventory identifier property, and then the consumer or user sets the inventory identifier property, the unit price property may be incorrect if there is an association between the item identified by the inventory identifier property and its unit price. An author designing such application will add code or instructions to handle this situation. However, in view of the complexity of the application this code may have to be duplicated for every property that needs to be set, and adjusted as necessary given the property that is being set. A heavy burden is thus placed upon the application author to maintain accuracy and consistency in order that the application executes correctly.
A method and/or system that can simplify the validation of properties would be highly beneficial.